Hi Brad,
It is quite complicated but this is the manner KMotion.exe and KMotionCNC.exe does it.
The KMotionDLL libraries keep track if the board is opened and connected or not. Any call to talk to the board to do anything the Libraries will first try to open the connection to the board if it is not already open. If it can't open then it fails, displays a message box, and returns an error code to the caller. So for example if someone pushes a "Jog" button with no board connected it will display the "No board connected error message" and return an error code so that the caller knows not to try any more commands. The application also has the option to first check if a board is connected before attempting to issue any command so as to not generate any Library error (KMotion and KMotionCNC don't do this).
If an error occurs during a communication (ie unexpected disconnect) the Libraries will remember that the disconnect occurred and return an error code and any subsequent command after the board is re-connected will require a re-sync where buffers on both sides are flushed of any leftover garbage from any previous communication.
The main status update timer loop is as shown below. It calls WaitToken with a 100ms time out to see if the board is available. There are 3 possible outcomes:
#1 Returns within 100ms with KMOTION_LOCKED = the board is connected, open and ready, locked for exclusive use by the thread
#2 Returns immediately with KMOTION_NOT_CONNECTED = No USB device is connected
#3 Returns after 100ms with neither of above = Board is present but somebody else has it locked for a long time.
While reading the status if any error is detected (invalid data for example) it makes a library call "Failed" to make sure the libraries are aware something is wrong and a flush/re-sync is required before any new communication.
I think overall it works quite well. If no board is connected then on application startup the application just periodically polls using very little cpu time looking for a board to be present. If a board is or becomes present then it automatically connects and starts displaying status. Only if after connected a disconnect occurs it displays a Disconnect Message. I think the Disconnect message is probably the worst part of the overall scheme, but normally this shouldn't happen and if it does, silently disconnecting and re-connecting might be dangerous as the board may have been re-booted and in an improper state.
There has been at least one request for a mechanism to inhibit message boxes from the Libraries. I think this makes sense and we will probably add this. Maybe the App registers a call back so that the app can either handle them or ignore them. It isn't easy to do because some errors occur in the KMotionServer.exe which is a different process.
HTH
TK
{
result=TheFrame->KMotionDLL.WaitToken(board,false,100.0);
if (result == KMOTION_LOCKED)
{
// Note only service the console
// after we have the token so we
// are sure of no getting blocked
TheFrame->KMotionDLL.ServiceConsole(board);
// upload bulk status
if (GetStatus())
{
Interpreter.Abort();
// error reading status
TheFrame->KMotionDLL.Failed(board);
}
TheFrame->KMotionDLL.ReleaseToken(board);
UpdateScreen( true);
}
else
UpdateScreen( false);
CString NewTitle;
if (m_Thread != -1)
{
if (result != KMOTION_NOT_CONNECTED)
NewTitle = "KMotionCNC - Connected - " + FileNames[m_Thread];
else
NewTitle = "KMotionCNC - Disconnected - " + FileNames[m_Thread];
}
}
Group: DynoMotion |
Message: 2485 |
From: Brad Murry |
Date: 11/30/2011 |
Subject: Re: losing and regaining connection to kflop elegantly |
Hello Tom, First, to clarify things- when you talk about flushing and re-syncing; that is handled automatically on the KMotion side right? Other than that, checking for a connection before each member call sounds like the way to do things. I’d also like to request said mechanism. It would be great to have a callback that I can use to set a ‘connected’ flag. I could just check that flag instead of querying the connection before each call. Of course that callback would be nice for signaling connection too. Thanks again, Brad Murry From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes Sent: Wednesday, November 30, 2011 6:32 PM To: DynoMotion@yahoogroups.com Subject: Re: [DynoMotion] losing and regaining connection to kflop elegantly It is quite complicated but this is the manner KMotion.exe and KMotionCNC.exe does it. The KMotionDLL libraries keep track if the board is opened and connected or not. Any call to talk to the board to do anything the Libraries will first try to open the connection to the board if it is not already open. If it can't open then it fails, displays a message box, and returns an error code to the caller. So for example if someone pushes a "Jog" button with no board connected it will display the "No board connected error message" and return an error code so that the caller knows not to try any more commands. The application also has the option to first check if a board is connected before attempting to issue any command so as to not generate any Library error (KMotion and KMotionCNC don't do this). If an error occurs during a communication (ie unexpected disconnect) the Libraries will remember that the disconnect occurred and return an error code and any subsequent command after the board is re-connected will require a re-sync where buffers on both sides are flushed of any leftover garbage from any previous communication. The main status update timer loop is as shown below. It calls WaitToken with a 100ms time out to see if the board is available. There are 3 possible outcomes: #1 Returns within 100ms with KMOTION_LOCKED = the board is connected, open and ready, locked for exclusive use by the thread #2 Returns immediately with KMOTION_NOT_CONNECTED = No USB device is connected #3 Returns after 100ms with neither of above = Board is present but somebody else has it locked for a long time. While reading the status if any error is detected (invalid data for example) it makes a library call "Failed" to make sure the libraries are aware something is wrong and a flush/re-sync is required before any new communication. I think overall it works quite well. If no board is connected then on application startup the application just periodically polls using very little cpu time looking for a board to be present. If a board is or becomes present then it automatically connects and starts displaying status. Only if after connected a disconnect occurs it displays a Disconnect Message. I think the Disconnect message is probably the worst part of the overall scheme, but normally this shouldn't happen and if it does, silently disconnecting and re-connecting might be dangerous as the board may have been re-booted and in an improper state. There has been at least one request for a mechanism to inhibit message boxes from the Libraries. I think this makes sense and we will probably add this. Maybe the App registers a call back so that the app can either handle them or ignore them. It isn't easy to do because some errors occur in the KMotionServer.exe which is a different process. result=TheFrame->KMotionDLL.WaitToken(board,false,100.0); if (result == KMOTION_LOCKED) // Note only service the console // after we have the token so we // are sure of no getting blocked TheFrame->KMotionDLL.ServiceConsole(board); // upload bulk status if (GetStatus()) // error reading status TheFrame->KMotionDLL.Failed(board); TheFrame->KMotionDLL.ReleaseToken(board); true); else false); if (m_Thread != -1) if (result != KMOTION_NOT_CONNECTED) "KMotionCNC - Connected - " + FileNames[m_Thread]; else "KMotionCNC - Disconnected - " + FileNames[m_Thread]; }
From: bradodarb <bradodarb@...> To: DynoMotion@yahoogroups.com Sent: Wednesday, November 30, 2011 4:23 PM Subject: [DynoMotion] losing and regaining connection to kflop elegantly Hello Tom,
I want to be able to detect loss of connection in a friendly way as well as try to reconnect once a board is present. As it sits I will need to restart MM to get a new handle, and it will not even start if no card is plugged in.
I have a few ideas rolling 'round on how best to go about this but I would like your input as I don't really know what if any particular processes need to be killed.
Thanks for your time,
Brad Murry
|
|
Group: DynoMotion |
Message: 2490 |
From: Tom Kerekes |
Date: 11/30/2011 |
Subject: Re: losing and regaining connection to kflop elegantly |
Hi Brad,
Yes re-sync is handled on the KMotion side. You should be able to maintain a flag from the status loop I've described.
Regards
TK
Group: DynoMotion |
Message: 2491 |
From: bradodarb |
Date: 11/30/2011 |
Subject: Re: losing and regaining connection to kflop elegantly |
Hello Tom,
Yes, I will definitely add that loop to the MM for next build.
I think pushing the responsibility to the user application as you did with KMotion and KMotionCNC is the way to go.
Thank you,
Brad Murry
--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Brad,
> Â
> Yes re-sync is handled on the KMotion side. You should be able to maintain a flag from the status loop I've described.
> Â
> Regards
> TK
>
> From: Brad Murry <bradodarb@...>
> To: DynoMotion@yahoogroups.com
> Sent: Wednesday, November 30, 2011 9:11 PM
> Subject: RE: [DynoMotion] losing and regaining connection to kflop elegantly
>
>
> Â
> Â Â Hello Tom,
> Â
> Â
> Â Â Â First, to clarify things- when you talk about flushing and re-syncing; that is handled automatically on the KMotion side right?
> Â
> Other than that, checking for a connection before each member call sounds like the way to do things. Iâd also like to request said mechanism. It would be great to have a callback that I can use to set a âconnectedâ flag. I could just check that flag instead of querying the connection before each call. Of course that callback would be nice for signaling connection too.
> Â
> Thanks again,
> Brad Murry
> Â
> From:DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> Sent: Wednesday, November 30, 2011 6:32 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] losing and regaining connection to kflop elegantly
> Â
> Â
> Hi Brad,
> Â
> It is quite complicated but this is the manner KMotion.exe and KMotionCNC.exe does it.
> Â
> The KMotionDLL libraries keep track if the board is opened and connected or not. Any call to talk to the board to do anything the Libraries will first try to open the connection to the board if it is not already open. If it can't open then it fails, displays a message box, and returns an error code to the caller. So for example if someone pushes a "Jog" button with no board connected it will display the "No board connected error message" and return an error code so that the caller knows not to try any more commands. The application also has the option to first check if a board is connected before attempting to issue any command so as to not generate any Library error (KMotion and KMotionCNC don't do this).
> Â
> If an error occurs during a communication (ie unexpected disconnect) the Libraries will remember that the disconnect occurred and return an error code and any subsequent command after the board is re-connected will require a re-sync where buffers on both sides are flushed of any leftover garbage from any previous communication.
> Â
> Â
> The main status update timer loop is as shown below. It calls WaitToken with a 100ms time out to see if the board is available. There are 3 possible outcomes:
> Â
> #1 Returns within 100ms with KMOTION_LOCKED = the board is connected, open and ready, locked for exclusive use by the thread
> #2 Returns immediately with KMOTION_NOT_CONNECTED = No USB device is connected
> #3 Returns after 100ms with neither of above = Board is present but somebody else has it locked for a long time.
> Â
> While reading the status if any error is detected (invalid data for example) it makes a library call "Failed" to make sure the libraries are aware something is wrong and a flush/re-sync is required before any new communication.
> Â
> I think overall it works quite well. If no board is connected then on application startup the application just periodically polls using very little cpu time looking for a board to be present. If a board is or becomes present then it automatically connects and starts displaying status. Only if after connected a disconnect occurs it displays a Disconnect Message. I think the Disconnect message is probably the worst part of the overall scheme, but normally this shouldn't happen and if it does, silently disconnecting and re-connecting might be dangerous as the board may have been re-booted and in an improper state.
> Â
> There has been at least one request for a mechanism to inhibit message boxes from the Libraries.  I think this makes sense and we will probably add this. Maybe the App registers a call back so that the app can either handle them or ignore them.  It isn't easy to do because some errors occur in the KMotionServer.exe which is a different process.
> Â
> HTH
> TK
> Â
> if(ReadStatus)
> {
> Â Â Â result=TheFrame->KMotionDLL.WaitToken(board,false,100.0);
> Â Â Â if(result == KMOTION_LOCKED)
> Â Â Â {
> Â Â Â Â Â Â Â // Note only service the console
> Â Â Â Â Â Â Â // after we have the token so we
> Â Â Â Â Â Â Â // are sure of no getting blocked
> Â Â Â Â Â Â Â TheFrame->KMotionDLL.ServiceConsole(board);
> Â Â Â Â Â Â Â // upload bulk status
> Â Â Â Â Â Â Â if(GetStatus())
> Â Â Â Â Â Â Â {
> Â Â Â Â Â Â Â Â Â Â Â Interpreter.Abort();
> Â Â Â Â Â Â Â Â Â Â Â // error reading status
> Â Â Â Â Â Â Â Â Â Â Â TheFrame->KMotionDLL.Failed(board);
> Â Â Â Â Â Â Â Â }
> Â Â Â Â Â Â Â Â TheFrame->KMotionDLL.ReleaseToken(board);
> Â Â Â Â Â Â Â Â UpdateScreen(
> true);
> Â Â Â }
> Â Â Â else
> Â Â Â Â Â Â Â UpdateScreen(
> false);
> ã
> Â Â Â CString NewTitle;
> Â Â Â if(m_Thread != -1)
> Â Â Â {
> Â Â Â Â Â Â Â if(result != KMOTION_NOT_CONNECTED)
> Â Â Â Â Â Â Â Â Â Â Â NewTitle =
> "KMotionCNC - Connected - "+ FileNames[m_Thread];
> Â Â Â Â Â Â Â else
> Â Â Â Â Â Â Â Â Â Â Â Â NewTitle =
> "KMotionCNC - Disconnected - "+ FileNames[m_Thread];
> Â Â Â Â }
> Â }
>
> Â
> From:bradodarb <bradodarb@...>
> To: DynoMotion@yahoogroups.com
> Sent: Wednesday, November 30, 2011 4:23 PM
> Subject: [DynoMotion] losing and regaining connection to kflop elegantly
> Â
> Hello Tom,
>
> I want to be able to detect loss of connection in a friendly way as well as try to reconnect once a board is present. As it sits I will need to restart MM to get a new handle, and it will not even start if no card is plugged in.
>
> I have a few ideas rolling 'round on how best to go about this but I would like your input as I don't really know what if any particular processes need to be killed.
>
> Thanks for your time,
>
> Brad Murry
> Â
>
|
|
| | | |